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INTRODUCTION 



The goal of the Nava) Postgraduate School Signal 
Processing and Display Laboratory is to provide a facility 
for research and education in the field of computer science. 
The laboratory is built around a oair of Diaital Equipment 
Corporation PDP-11/50 orocessors, One processor is 
primarily used to service multiuser program development 
activities. The other processor supports several graphics 
aisolay devices ana provides a dedicated environment for 
research and development in the areas of operatina svstems, 
computer graphics ana signal processing. Figure 1 shows the 
present hardware configuration of the laboratory. 

The UNIX operatinc system f 7 3 / a time-sharina system 
developed at Fell Laboratories^ was chosen as the system 
best suited to support the goals stated above. UNIX's 
inherent file svstem flexibility and the availability of 
system source ccae written in the high level crcgrammina 
language, " C " , orcvide an excellent environment for 
operating system development and research. The availaoilitv 
of a dedicated processor as a ae ve 1 opmen t a 1 tool further 
enhances this environment. 

Due to the unique and demanding requirements placed on 
the display processor's operating system by grannies devices 
and signal processing equipment, it was determined that the 
standard version of UNIX in use ( henceforth simply referred 



Q 



to as UNIX ) was unsatisfactory. This thesis proooses an 



extension to the UNIX system in the form of a new memory 
management scheme. Ihe approach taken was to implement 
process segmentation with provision for data space 
allocation and alignment within a specified memory region. 
This approach was feasible and attractive because the 
PDP-11/50 is equiopea with a memory management unit ( M M U ) 
that supports segmentation. Aad i t i ona 1 1 y t segmentation 
provides extra flexibility in resident process manipulation. 
UNIX allocates process space as a single contiguous unit in 
main memory. Segmentation allows management of process 
segments as separate entities. This provides the necessary 
tool for selective allocation of memory soace to an 
individual segment. 

This latter feature is particularly attractive in a 
system confiaured with multioorted memory. As shown in 
Figure 1/ the display processor has access to two dual- 
ported memory areas? one shared with a signal processina 
controller^ the other shared with a slave processor for the 
refresh Graphics display devices. Due to the real-time 
requirements of these oev ices/ independent access to data in 
the shared region is necessary. Otherwise, the display 
processor will not be able to support mu 1 t i d r oc ramm i ng . A 
segmented memory manager would provide the features 
necessary to support these real-time reauirements. 

Two modifications of the UNIX operatina system were 
implemented and tested as a result of this thesis. One was 
a previously designee [ u ] , out un implemented/ segmented 



memory manager version (SUNIX) 



The otnerr 



a shared- 



segmented version (S SUNIX)* was a further modification of 
SUNIX which implemented the alignment of a orocess's data 
soace within a shared memorv region. Real-time processing 
was supported bv loc<ina the orocess image in main memory 
once the shared region had been acquired. 

Testing of SUNIX and S SUNIX included benchmark 
measurements and operation in the general multiuser 
environment. Performance was almost identical to that of 
UNIX. Additionally* S SUN IX was tested on the disolay 
processor and successfully fulfilled the objective of data 
soace alignment with system orotect ion. Amplification of 
these results is orovidec in Cnaoter V of this thesis. In 
addition* recommendations are included for aoplications and 
utilization of SUNIX and SSUNIX in the Sianal Processing and 
Disolay Laboratory. 
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FIGURE 1. Signal Processing and Display Laboratory 




II. BACKGROUND 



A. PREVIOUS WORK 



Three previous thesis Projects which are closelv 
associated with the development o* SUNT X ana S SUN IX are 
discussed below. It should be noted that a soeci ^ ic area of 
concern in all three Daoers is the develooment of svstem 
supoort for the soecial devices on the display crocessor. 



1. Partitioned Segmented Memory ^anaaer 

In this thesis [ A ] , Emery reports an investigation 
of the apo 1 i c ao i 1 i t y of oaaing ana segmentation to memory 
management in UNIX. Two memory managers were aesigned to 
supoort this investigation: a oartitioned segmented version 

( P S U N I X ) » and a simpler segmented version (SUN IX). The 
orimary consideration in the design effort was that tne 
segments be separate and independently manageable in main 
memory. The segmentation chosen was the existinc natural 
division into a process control olocfc, a data segmenr 
(including non-shareo text) i and a User stack. Shared text 
segments were handled in mucn the same manner as in UNIX. 
SUNIX was designee to manaae each complete seomenf 
inaependently. It was this design effort that orovioea a 
foundation for the develooment of S SUNIX. PSUNIX further 
broke down each of tne segments into var i aol e*s i ze blocks. 

bv 



Test i ng 



of PS UNIX was accompli snea 



usma 



penchmar* measurements to analyze its performance in 
relation to UNIX. Trie experimental results clearly 
indicated that the performance of PSUNIX and UNIX were 
nearly identical over a wide range of available User memory 
space* Emery suggested that this approximate eauality of 
perqormance indicated that the disadvantage of the increased 
amount of swapping in PSUNIX was offset bv a reduction in 
the number of processes swapped. He attributed tnis to 
reduced external fragmentation with PSUNIX, However/ oue to 
the relative complexity of PSUNIX, Emery recommends that the 
simpler SUN IX be completed and implemented as a viable 
a 1 t ernat i ve . 

2. Inter-Processor Graphics Support System 

Visco [121 investigated a multiple processor system 
conf iauration to support a real-time, interactive graphics 
package. UNIX was redesigned to implement a real-time 
system call and a master-slave relationship between the 
display processor and a dedicated graphics processor. 
Specifically, he designed the system support routines 
necessary for integration of fhe PDP-11/50, PDP-11/34, and 
Vector General f V G ) Display Processors. For ^est ina 
purposes, inter-processor communications were simulated on 
the PDP-11/50, since the D DP-ll/34 slave processor was not 
ava liable for use . 

The master-slave processor configuration was 
conceived as an answer to the problem of refresh graphics 
devices having a hian level of direct memory access fD M A) 
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requests and a reoui rement for real-time system support. 
DMA is the transfer* of data directly to or from memory by a 
peripheral aevice/ without processor supervision. This 
conf i qurat i on reauired shared memory and the system support 
software to alian a process image in the sharec region. 
Memory management hardware on the slave processor f 2 3 
permitted a 32 tnousand (K) word address range. The svstem 
designed ov Visco allocated the entire process imaae on a 
3 2 h word boundary. System orotect ion was not achieved since 
other processes were allowed to overiac into this region. 

Visco sugoested an i mo 1 emen t a t i on of Emery’s SUMIX 
as a method of allocating onlv the qraphics process’s data 
space to the shared region of memory. Since DMA by the 
slave processor, acting in behalf of the graphics device/ 
was highly concentrated in data scace/ this memory 
allocation scheme would more efficiently utilize the limited 
amount of shared memory. SSUMIX/ with the added features of 
generalized multioorteo memory applications and system 
protection, was developed as a result of this sugaest ion. 

3. Loosely -Couoled Multiprocessor System 

Vi sco’s work was directed primarily toward the main 
processor in the proposed multiprocessor system for tne 
laboratory. A thesis by Gray [ 5 ] addresses the development 
of an operating system for the slave processor. Although 
not directly related to the problem of memory management in 
UNIX, this paper is mentioned here to emphasize the General 
trena o f thesis work cone in support of the laooratorv’s 
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refresn graohics devices. Furthermore* recommenaat ions in a 
later chaoter of this oaoer soeci f ical I v adaress the 
integration of SSUMIX into the multiprocessor environment. 

B. GENERAL SYSTEM PROPOSAL 



As 


indicated 


i n 


the orev i ous 


section, the 


soeci 


t 1 c 


system 


proposed 


by 


this 


t h e s i s 


was desianed primarily 


t o 


per form 


data space 


a 1 


i g n m e n t 


i n a 


she red memo ry 


area 


f o r 



resident signal processina and refresh araphics processes, 
however/ the actual modifications to UNIX were designed to 
offer more general applications. SUNIX was implemented as a 
general ourpose operating system with segmented memory 
management. The differences between UNIX and SUMJY are 
transparent to the User. SSUNIX provides the ability to 
align a process’s data space within any given area of User 
memory space. Location and size of this memory reaion/ 
which was intended to correspond to shared memory assets, 
can be specified at svstem aenerat i on time. The limitations 
of UNIX in a system conf iaured with devices * h i c h aemand 
heavy D V A and real-time svstem support are discussed. Tne 
general concepts behind the design of SUNIX and SSUMIX are 

also presented. 

/ 

l. Limitations of the °resent System 
a. bus Allocation 

As shown in Figure 1/ all PDP-11/50 components 



and peripherals connect to and communicate with each other 



over a high-soeed# bidirectional/ asynchronous bus known as 
the UNIbUS (33 • Devices gain access to the UNIBUS via an 
arbitration unit. This unit aranf s bus mastership based on 
a multilevel priority scheme. Each device on the U Nib US is 
assigned a hard-wired priority which is recoanizea by the 
arbiter. A device is aranted i m mediate mastersnip when a 
request is made and no device of equal or higher priority 
has control. D M A reouests from oerioheral devices have 
highest priority. The central orocessing unit (CPU) has the 
capability to control or release the bus by varying its own 
priority level. This makes it possible for devices to 
access main memory with almost no processor intervention. 

Devices which require a large amount of DMA 
place heavy demands on the UNIBUS. A oroblem arises in a 
multiprogrammina environment when a process is runni nq at a 
high schedulina oriority (as with real-time orccesses)/ and 
also reauires nigh oriority and heavy bus utilization * o r 
DMA. In this case/ all other orocesses are essentially 
suspended since thev cannot gain access to the i 1 NIB US. 
Refresh graphics devices reauire heavy bus utilization for 
processing the display list. In the case of the VG devices 
in the laboratory, tne display list/ located in the res i cent* 
graohics orocess’s data soace/ must be processed every one- 
fortieth of a second. It is thus necessary to lock the 
active display list in memory. If the list were not in 
memory at the time of a refresh cycle an ino^ainate delay 
would occur/ causina the display to flicker or fade. 



As noted previously/ 



dual-oortea memory was 



conceived as a solution to these oroblems. With the 
peripheral processors each assigned a seoarate bus attached 
to memory ports ooposite the main processor/ interference 
durina DMA could be virtually eliminated. The proolem which 
remained was the allocation of a process's data snace to one 
of the shared memory areas. Visco's design at temotea to 
solve this problem specifically for V G processes. S S U N I X 
was designed to solve the oroOlem for more general 
aop 1 ications. 

b. Memory Allocation Scheme 







In UNIX 


/ while 


the p roc es so r 


i s 


execut i no 


i n 


oeh a 1 f 


o f 


a process 


/ its image must reside 


i n 


main memory 


a s 


a s i n a 1 


e 


contiguous 


unit. 


Uni ess s wapo i na 


i s 


necessary/ 


the 


i maae 


remains in 


memo rv 


durina the execution of other 


processes 


. When 


the CPU 


is executing 


a 


p roc es s / 


MMU 



registers are loaded so the Process can access onlv its own 
image and, if applicable/ a text segment shared with other 
processes . 

The memory allocation scheme used in UNIX is 
cased on a " f i r s t - f i t '* alaoritnm. That is/ the orocess 
imaae is allocated space in the first free area in the 
system's free-list which can accomodate it. With this 
scheme/ selective allocation and alignment of memory space 
in a oarticular region of memorv is impossible. Tpis is 
unsat i sf actorv in a system configured witn multioorted 
memory. As an example/ the Computer Si anal Processors 



Incorporated CSP 125 controller can access only t’^at cortion 



of memory inaicatea in Figure 1. Any process that 
communicates with the C S P 125 must have its data space 
located in that area of memory. 

2. General Features of the Prooosed System 
a. Segmentation 

The initial Decision that had to De made to 
solve the problems stated above was: what type of memory 
management modifications to UNIX were required to provide a 
general and efficient ooerat ing system which would suoport 
alignment of a resident process’s data space in a aiven 
region of memory. The segmented memory manaaer desi anea by 
Emery (SUNIX) was chosen as a basis for the intended 
modifications. Segmentation had several advantages which 
maae this choice attractive. Process imaaes in UNIX consist 
of several logically independent segments. Although not 
managed seoarately, this natural division orovia<°s an 
appealing basis for segmentation. M od i f i c a f i on s to tne 
existing memory management routines to imolement SUM IX * ere 
straiahtforward and relatively simple. 

The segmentation chosen also proved to oe an 
efficient way to handle dynamic changes in the size of User 
data and stack areas. In UNIX, when the User space crows 
beyond tne available contiguous memorv soace/ it is 
necessary to reestablish the entire process image in main 
memory. This is accomplished by cooyinc the process image 
to a new free area of sufficient size. Since tnere is no 

on 



hardware 



facility 



the p DP- 11/50 for a ” olock move" in 



memory* this is a major source of memory management 
overhead* The cost of the copv ooeration is about 10 
micro-seconds per wore [41. This figure is even worse if 
soace is not readily available for the larger image and 
other processes have to swapped out to make room. In SUM IX 
the User's data and stack are managed i ncependen t 1 y . Growth 
of either area reauires reestablish ina only that seoment in 
memory. Total overhead due to dynamic in-core expansion is; 
therefore* reduced. 



b. Data Space Alignment 

After decidina on S U MIX as tne operating system 
which would Dest serve the Purposes of this thesis* a method 
of Positioning a process's aata soace at a particular 
location in main memory had to be 'developed. Detailed 
analysis of the memorv manaaement routines in Doth SUNIX and 
UMIX was necessary before proceeding. The method chosen* 
and implemented in SSUMIX* was a direct extension of SUNIX. 
No modification to the segmentation scheme was necessary, 
and only minor modifications to the other memcrv management 
routines were reaui red. The general approach taken was to 
implement the necessary changes by adding several system 
routines to acquire* allocate* and release a shared memorv 
asset. System calls were implemented to perform these 
functions for processes requiring shared memory. 

Providing system protection was a secondary goal 
in the desian of a memory manager for SSUMIX. Tne ccnceot 
of system protection implies that inadvertent destruction of 
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vital process infornation> oarticularly the process control 



information used by the 


ooe r a t i ng 


syteinr 


will 


not occur. 


Address 


range limitations 


of the 


per ipheral 


processors 


prevent 


their manipulation 


of data 


i n 


memo ry 


1 oc a t 


ions 


outside 


of the shared region 


SSUNIX 


a 1 lows 


only 


the 


data 


space 


of processes communicating with 


these 


dev ices in 


this 


region. 


The combination of 


these two 


features Droviaea 


the 


svs t em 


orotection desired. 
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THE UNIX OPERATING SYSTEM 



HI. 



Thus far in this thesis# the UNIX ooerating system has 
been ai scussed in general terms. This chaoter orovides a 
more detailed discussion of the concepts of svstem 
operation. Concepts in the design of the memory managers in 
UNIX, SUN IX and S S U N I X are also presented. This cnapter 
provides the background necessary for understanding the 
modifications made to UNIX to implement SUN IX and 3 S U N I X . 

A • CONCEPTS OF OPERATION 

UNIX [71 is a terminal oriented# time-sharing operating 
system developed at Bell Laboratories for the Digital 
Eauipment Corporation (DEC) PDP-11 family of minicomputers. 
Most of the source code for UNIX is written in M C" [ ° ] # a 
high level systems implementation lanauage. The remainder 
of the source is written in "as" [10], a Pell Laboratories 
variant of PDP-11 assembly language. 

Multi-tasking in UNIX is Performed on a basic unit of 
work called the orocess. A process consists of system 
control information# executable instructions# ana data, 
/jhen the operatina system is " boo t s t r apced ” into memory at 
system initiation time# it "handcrafts” its first two 
processes. Process 0 is the master control process (the 
scheduler "loop”) which executes until UNIX terminates. 



Process 1 initializes the ooerating environment for other 



processes in such a manner that all subseouent orocesses are 
its descendents. All other processes are executions of 
proaram files from the UNIX file system* 

Descenoents of a process are created by execution of the 
"fork" system call. This svstem call replicates the callina 
process* creating a new (child) process that has a unioue 
process number. The or i qi nal process* called the parent* 
can continue execution or temoorar i 1 y susoena itself until 
the cnild terminates. A child croc ess mav either continue 
execution of the same proaram or invoke a new orogram into 
execution. New processes are invoked by "exec”* a system 
call that "overlays" the callina orocess with an executable 
file from the file system. Child processes may also spawn 
children of their own. rthen any child completes execution* 
it terminates by means of the "exit" system call. "Exit" 
notifies the oarent of the child* s termination. 

The primary role cf Process 1 is to create a child 
process for each of the terminals in the svstem. These 
processes ooen their assigned terminals* oromot for a user 
to log in* and then await a reoly. Once a user nas iogged 
in* the child invokes a new proaram (using "exec") called 
the Shell. The function of the Shell is to interpret 
commands from the terminal and create children which 
accomplish the desired operation. When the user 1 oas off* 
the Shell process for his terminal is terminatec. p rccess 
1* which is then notified of that child* s demise* creates 
another chila for the terminal. The new child r^ooens the 



terminal and oromots for another loo in. 

From the User’s point of vi^w; the most imoortant role 
of UNIX is to provide a file system [7], There are 

basically three kinds of files suoported by the system: 
ora inary disk files/ directories/ and special files. 

Ordinary files contain whatever information the User places 
on it. Source orcgrams/ object moaules generated oy 

comoilers or assemblers/ and cure text are examples of 
ordinary files. Directories provide a mapping of ordinary 
file names to the files themselves/ thereby inducing a 
structure on the file system. All files in the system mav 

be located by tracing a path from the "root" directory to 

the desired file. User interface to each inout/ouput (I/O) 
device suoported by the system is through a de v i c e-soec i f i c 
special file. /nth this scheme/ I/O devices can be treated 
as ordinary files. 

B. MEMORY MANAGER DESIGN 



The UNIX memory manager is/ in concept/ a relocatable 
partitioned memory manaaer with sweeping ana limited 
segmentation. While the processor is executing in behalf of 
a process^ tne process image must reside in a continuous 
region in main memory. As already explained/ during tne 
execution of other processes/ a process may remain in memory 
unless scheduling of a higher priority orocess *orces it to 
be swapped out (copied) to the swap device. UNIX processes 
are logically divided into three parts: the U VECTOR/ tne 






User data soace» and the User processor stack 



If a process 



requires use of shared text » i t s oata space contains onlv 
data. Shared text is managed separately. 

The UVECTOR contains all process status information 
required bv UNIX while the process is resident in core. 
Other process status information# which must remain 
addressable throuahout the life of the process# is contained 
in a system control block called a PROC. In the case of 
shared text# the PROC contains a pointer to vet another 
system control block called a TEXT. This block contains ail 
information necessary to control the sharing of a text 
segment by one or more orocesses. Shared text# if reauired# 
is established in memory indeoenaentlv of the orocesses 
which are sharing it. If a process shares text# "exec" 
checks to see if a copy of the text segment is already 
available in the system. If it is not# a copy is created. 

User address space of a texfshari na process mav d e 
created with separate instruction space (I-soace) ano oata 
soace (D-space)# or with combined I-soace and D-soace. User 
address space for non-sharina orocesses is established with 
combined instruction and data soaces. If the i-soace and 
D-soace of a orccess are combined# there is no 
differentiation between instructions and data. T n e file 
type 17] of an executaole file is used bv "exec” to 
estaolish a separation flag in the UVECTOR. This flaa is 
used to control the method by which the address soace for a 
text sharing crocess is established. The scared text 
segment of a process with' seoarate address soaces is 
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addressed beginning at User I-scace address 0; data is 
addressed beginning at User D-soace address 0. If a orocess 
with conjoined address spaces Has shared text/ the text 
segment is addressable beginning at address 0 in both I- 
soace and D-snace. Its data is addressed in both I-space 
and 0-space/ beoinninq at the first 4 K word boundary above 
the shared text segment. For processes without shared text/ 
the text is addressed beginning at address 0 in the combined 
I-soace and D-soace? and its data is addressed beoinninq at 
the first word boundary above the text. The User’s 
processor stack is adcressed extending downward from the 
highest address in D-space or combined I-space and 0-space. 

PDP-11/50 oaae address registers ( P A R s J ana page 
descriptor registers t P D F s ) are loaded when a process image 
is brought into memorv or its address soace is 
reestablished. PARs are used by the ^MU to translate 
virtual addresses to physical memory addresses. PDRs are 
used to describe a se** of attributes about a resident 
process’s pages. A page in UNIX can be thought of as a 
partition of a process imace which can be up to 4K words in 
lenath. Access control specified in the p DRs is read only 
for shared text cages and read-write for all other naoes. 

User data soace may vary dynamically if required a urina 
execution of a process. A system call/ ’’break"/ is provided 
in UNIX to alter the size of the data area. Additional!// 
the size of a process image may be increased ov dynamic 
growth of the User processor stack. iNhen this occurs/ the 
system automatically increases the amount of scace provided 
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for the process. In both of these cases/ UNIX must 
reestablish the entire process image in main memory. As 
mentioned oreviously/ one of the primary benefits of 
segmentation is indicated here. SUNIX and SSUNIX reauire 
that only the segment whicn changes size be rees t ao 1 i shed . 

1. Segmentation 

Segmentation of shared text is already well 
supported in UNIX. SUN IX and SSUNIX further divide process 
images into the three natural segments mentioned before: 
UVtCTOR/ data space (including non-shared text)/ ana User 
stack. Allocation of memory space for a process is 
accomplished by separately establishina each segment in a 
free area large enough for it. Contiguous allocation in 
memory is possible/ but not required. Swac space for a 
process is still allocated in a cont iauous oartition on tne 
system's swap device. However/ due to the separation of 
segments in main memory/ up to three copy operations are 
required each time a process is swapped to or from the swao 
device. In UNIX, only one copy operation is reauirea. 
Thus/ there is an increase in svstem overhead with seomented 
memory management. There is/ however/ a compensating 
advantaoe to segmentation: a reduction of overhead (secment 
copying) results from independent manaaement ct dafa and 
stacK segments if dynamic growth of one of these searerts is 
r equ i red. 
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2 . Allocation of M e m o r v Soace 

The basic quantum of memory soace in 1 I X is a 
64-byte area called a clock. This is the smallest ouantum 
supoortea by the POP-1 1/50 M M U . Memory soace for each 
process is assigned from a free memory mao maintained oy the 
operating system. This map, which is establishea at system 
initiation time based on ohysical memory configuration, 
contains the base address and size (in blocks) of each 
unallocated area of User memory scace. Addresses in the mao 
are increasina in order and represent the onvsi cal block 
number of the free area to which they refer. Tn® operating 
system is established beginning at ohysical address 0. User 
memory space beains at the first block boundary aoove the 
system code . 

Maintenance of the free memorv mac is performed oy 
the memory management orimi t i ves M m a 1 1 o c H and H m f r e e " • 
These system routines are also generalized to cerfnrm 
maintenance of all other system free maps; for examole, tne 
swao mao, and the shared memory maps (described later) in 
SSUNIX. The function of malloc” is to locate an area of 
given size in the given mao, update the map to reflect tne 
allocation of the area, and then return the physical block 
number of the allocated area to the calling routine. The 
algorithm used in "mal loc H is " first-fit". That is, the 
free mao is searched seauentially, beginning witn tne * i r s t 
entry, until an area of sufficient size to satisfy n e 
request is found. Tf the requested soace is no f available, 
a zero value is returned to the caller. The function of 
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“mf ree" is to free the area specified Oy t h e callina 



routine. The reaion soecified is sorted back info the free 
map and combined on one or both ends if possible- In UNIX/ 
processes are allocated space based on the * l z e of the 
entire process image. In SUNIX and SSUNIX, each seament of 
a orocess is allocated memory space separately based on the 
segmen t size. 

3. Mu I t l ported Memory 

Regions of multi ported memory are often cesirable to 
support peripheral devices which have uniaue DMA 
requi regents. Examples are devices which have hardware 
address ranee limitations or require real-time memory 
access. Soecific applications of multioorted memory in the 
Signal Processing and Display Laboratory have already been 
d i scussed. 

To support multi ported memory/ the operating svstem 
must be able to align a orocess or process sequent in the 
multioorted memory reaion. UNIX does not have this 
capability. As explained in the previous section/ %a1 loc” 
assigns memory space from the User free map rased on a 
* first-fit” algorithm. With this alaorith^, alignment 
within a specified region of memory would ^ e purely 
coincidental. Furthermore/ since 0 M A oy a nerirr°ral device 
to UvECTQR or stack addresses violates system security/ only 
the data segment is claced in thp multiported reaion. ihjs 
implies that seamentafion is a desirable memory management' 
scheme in a system confiaured with multioorted memory. For 



2 9 



this reason/ SUNIX was chosen as the basis for devel ooment 



of mu 1 t i po r t ed memory system support. Mthouah there was no 
provision for data seament alignment in SUNIX, the method of 
process sedimentation directly supported the desian effort 
undertaken by this author. 

In order to investiaate multioortea memory 
applications in UNIX/ a shared-seqmented memory ^anaaer 
(SSUNlX) was desianeo and imolemented. S SUNIX crcvio°q t n e 
capability to alian a c a 1 1 i n a Process’s data segment in a 
shared memory region, and to ensure system projection by 
c 1 ear i nq all other processes from that region, c ree memory 
maps were established and maintained for each scared core 
area. Processes recuested the sharea memory asset* via a 
svstem call ("getshr") , A system routine was designed which 
checked the User free memory map to determine if the 
requested region was free. If the area was free, it was 
removed from the User free memory mao and the data space of 
the calling User process was moved to the sharea r e a ion. 
The "mal 1 oc " svstem call was used to allocate space for the 
data seqment in the requested shared reaion. If the area 
was in use dv another memo ry -s h a r i nq process, the data 
segment of the callinc process was simply allocated in *he 
shared memory map and then ** o v e d to the region. It the a r e a 
was in use by other non-m e mory-sha r ing processes, these 
processes were swapped out of memory until t * e area was 
clear. The data seament of the call i na User process was 
then allocated in the shared memory mao ana mm yea to the 
region. 
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In each o* the above cases* after a scared memory 



region had been acaui red for a memorvshar i na process* non- 
memory-sharina orocesses were not allocated space within the 
bounds of the snared reqion. Additionally* the calling 
process was locked into memory so it would not be swapped 
out of the area. Another system call ("freeshr” ) was 
implemented to release a process’s shared memory asset and 
unlock the process imaoe. This system call updated the 
shared memory map. If no other memo r y - s h a r i ng orocesses 
remained in the reoion* the entire shared memory area was 
returned to the User free map. 
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MODIFICATIONS TO UNIX 



A. GENERAL 

Modifications to tne UNIX ooerat i ng system to oroouce 
SUN IX were oerformed by Emery (4] in m i d - 1 9 7 6 • The approach 
taken in the desion was to make the general structure of 
memory management familiar to those who understood the 
structure of UNIX* This aporoach led to a wei I -designed 
operating system which reaai 1 y supported further 

modifications and debugging* However, due to greater 
emphasis on the completion and testing of a partitioned 
segmented memory manacer (PSUNIX), SUN IX was not implemented 
at that time* Final implementation ana testing of SUM IX was 
a primary goal of this thesis project. S SUM IX was to be a 
direct extension of SUN IX. For this reason, modifications 
to UNIX required to imolement SSUMIX encompass those made 
for SUNIX. 

The changes necessary to imolement process segmentation 
with data segment alignment affected five general areas: 

1. Control Blocks 

2 . Memory Manaaement 

3. Swao Soace Allocation 

4. Shared Memory Allocation 

5. Support Proarams 



32 



Each of these areas is discussed in a subseauent section of 



this chapter. Tne appendices to this thesis orovide further 
documentation. Information on control block modifications 
is found in Aopendix A. M e m o r y management and shared core 
allocation modifications are described in Aopendix 6 . 

6. CONTROL BLOCKS 

UNIX control blocks are data structures used by the 
operating system to maintain information vital to system 
control. The only control block modification required to 
support process segmentation was the PROC. A list 
containina a PROC for each active process is maintained bv 
the system. In UNIX, a ?p qc contains the bloc* address of 
the UVECTOR and the size of the process image (which aoes 
not include shared text). In SUN IX and S S U N I X , a PPGC 
contains the block address of each of the process segments 
and the sizes of the data and stack segments. 

Several new control blocks were added to imolpment data 
segment alignment within a shared core area. S h v t M defines 
the upper and lower bounds of each shared memory reaion. 
Svstem shared core configuration changes reouirp modifyina 
the entries in this structure. SH M E M is usee at svstem 
initiation time to initialize two other shared memory 
control blocks. A SHAPE contains information about a 
particular shared-memory asset. The high and low bounds of 
the region/ a f 1 aa incicat mq whether or not the region is 
in use by another me mo r y -s h a r i no process/ and a^o^ner r 1 aa 
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used by "nal loc 



are maintained here 



A SHRMAP is a 



structure which contains a free memory map for each of the 
shared reqions. The maos in SHRM-^p were configured exactly 
like the other system free maps so they could be maintained 
by M m alloc” and " m f r e e " . 

C. MEMORY MANAGEMENT MODIFICATIONS 

Adaot i na the existing UNIX memory management routines to 
perform process seamen t a t i on was a st raight forwarc problem: 
in each routine that cealt witn a process i m a a e / t n * process 
imaae was managed as three independent segments instead of a 
single entity. Although simply stated/ solving this oroolem 
required many hours of familiarization with existing UNIX 
concepts/ and modifying several hundred lines of source 
code. Details of these modifications are not included here/ 
but are contained in Apoendix B. Copies of system source 
code cannot De included in this thesis due to UNIX non- 
disclosure agreements. However/ authorized Lit 1 IX User’s mav 
acquire macnine-readable copies by contacting tne Naval 
Postgraduate School . 

D. SWAP SPACE ALLOCATION MODIFICATIONS 

Swao space is allocated to a process * h e n if must oe 
swapped out of memory, and freed wnen the process returns to 
memory. A mao of free soace on the system’s swao device is 
maintained by %al loc" and ” m f r e e M . The s v s f e m routine 
M swao” is used * o transfer data oetween memory a n ^ tne swao 



device. 



SUN IX and SSUNIX processes consist of 



three 



segments that are i nceoendent ] y established in main memory. 
Moving a process image to the swao device requires a "swap” 
operation for each segment. Also* when shared text must oe 
established/ an additional "swap” operation is involved. 
Actual space on the swao device is allocated in a conMauous 
block. The disk address of the process is the address of 
the UVECTOR. Data (if any) and stack are located 
immediately following the UVECTOR. Shared text is 
separately established/ and retains it swap space until 
there are no longer any live orocesses which recuire it. 

E. SHARED MEMORY ALLOCATION MODIFICATIONS 

The basic ideas underlying the design of a shared- 
segmentea memory manager for UNTX (SSUNIX) were presented in 
Chaoter III. Actual oesicn work was started after S U M IX was 
implemented and had demonstrated satisfactory performance. 
The accroach taken in the development of SSUNIX was to add 
several system level routines to oerform the shared memory 
management functions* ana thus modify exist i no S U hi I X code as 
little as possible. Three new system routines were a d a e a : 
"Ocfnao”, to check the User free memory map; " s h a 1 1 o c " * to 
allocate a process's data sequent to a given snared core 
region; and M shf ree" * to free a process's shared core asset. 
Svstem calls *or User proaram interface *ith "shalloc" and 
"snfree" were also implemented. From a User's proaram/ 
"aetshr" acauires a shared core asset/ ana "freeshr" 



releases it 



A Drief summary of each new routine and the 



other modifications made to SUN IX is oroviaed in tne 
following oaragraohs. Detailed information can be found in 
Aopend i x B • 

The new procedure M c<mao" was the basic o r i m i t i v * used 
for shared core allocation. Its function was twofold: check 
the User free memory mac to determine if an area oetween a 
given high and lew block address was free/ and t h e n , if the 
area was free/ remove it from the free mac. The design of 
this procedure orovided an interest ina challenge. Once it 
was determined that the area was free/ several Doundary 
alianment conditions had to be considered in order to remove 
it from the free memory mao. The procedure "s^al !oc" 
performed the actual allocation and assignment of a 
processes data seament to the requested shared core area. 
It also locked the croces s image in memory. The alcorithm 
implemented was described in the orevious chanter. In order 
to prevent allocation of another orocess within the shared 
core region durinc the shared core acauisition by “shalloc"# 
a slight modification to the memory management primitive 
"malloc" was required. A orccess ' s shared memory asset was 
freed by M shfree". In addition to the system call 
interface/ this routine was called from the "exit” orocedure 
to ensure that a process’s shared core was released at 
process termination. 

Other modifications to SUN IX included: "main"/ to 
establish shared core regions ana initialize t n e i r 
respective control blocks; and "sysent"/ to oroviae system 
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entry points for the system calls "getshr" 



and 



f r ee s h r 



The source code reauired to build both SUNT X and SSUNIX can 
be found in the directory /usr/sys.suni k on the display 
processor’s file system. 

F. SUPPORT PROGRAM MODIFICATIONS 

One support proaram modification was reauired for SUN IX 
and SSUNIX. The Shell command "os" fill disolays certain 
information about active process status. It uses the PROC 
list to acquire this information for displav at the User's 
terminal. Since the structure of the PROC was modified to 
support process segmentation, certain variables used by "os" 
were invalidated. In particular, the address and size of a 
process imaae in U N T X were described in two variables in the 
PROC. In SUNIX and SSUNIX, five variables were reauired: 
UVECTOR address (its size is fixed at . 5 ft words), data 
segment address, data segment size, stack seament address, 
and stack segment size. To retain the displav format used 
bv "os", it was decided that all five of these attributes 
would not be presented. Since the User is normally 
concerned with only his data segment's address and size, 
these values were substituted for the existina values in 
"os" . The revised version of this rout i n» can be found in 
/ u s r / s y s . s un i x on the display processor's file svste". Th» 
object version of "os" found in /bin must be replaced with 
the revised object during SUNIX ana SSUNIX operation. 
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V 



EVALUATION OF PERFORMANCE 



A. OVERVIEW 

As stated throuohcut this report# completion and test i na 
of SUNIX was an integral part of this thesis ana a 
prereaui site for trie development of SSUNIX. A severe 
problem with the SUNIX memory manager had orevented its 
final implementation. This problem manifested itself in an 
inability to assemble certain programs. Since the assembler 
is used durina a oass of the " C " compiler# compilations were 
also affected. Several wee^s at the outset o * this thesis 
project were reouired to become familiar with# debug and 
test SUNIX. Once familiar with the concepts of system 
organization and memory management# Emery's desian reaci 1 v 
supoorteo the aeougqi ng effort at nand. Tne problem was 
eventually found and corrected in tne memory management 
routine M e x e c " . Development# imolementation and testing of 
SSUNIX followed. Performance of SUNIX and S SUN IX was 
evaluated in relation to UNIX. Additionally# tests were 
conducted which demonstrated the caoaoilitv o f SSUNIX to 
perform data segment allocation and deallocation of s h ared 
core. 
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COMPARISON WITH UNIX 



The method chosen to compare performance of UNIX, SUN IX 
and SSUNIX was to use the e 1 a o s e d execution time of a 
standard stream of processes (benchmarks)* A series of 
benchmarks was run to determine relative performance under a 
variety of operatina conditions. Available User memory was 
the variable used to establish these conditions* Two 
benchmarks were used: a monoprooramming benchmark, S t N C H 1 ; 
and a multiprogramming benchmark, 8 E N C H 2 . These benchmarks 
are essentially identical to those used ov Emery in his 
testing of P S U N I X . P o t h tSENCHl and B E N C H 2 contain the same 
sequence of UNIX commands. These commanas are documented in 
Ref. 11. APPENDIX C contains benchmark listings. The 
computer system used for the tests was the multiuser side of 
the laboratory configuration shown in Figure 1. A single- 
user environment was established with only the console on- 
line. The ourpose of this was to prevent the introduction 
of an added variable in benchmark performance due to 
processes aenerated by other Users on the system. The swao 
soace and file system used were located on RP05 disk units 
[3J . 

Table I presents the results of benchmark tests for 
UNIX, SUN IX and SSUNIX. Available IJs^r memory space was 
varied to evaluate performance over a wide range of s v s t e ^ 
conf laurations. Tim i no data was obtained by using the UNIX 
"time” command til]. Processes run under control of "time” 
are clocked bv samol ina processor state at the rate of bO 
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Hz. "Real” time reflects tne total elapsed time for the 



process and is reported to the nearest second* ’’User" time 
is the time scent in the User state (ie. executing the 
User’s prooram instructions) and is reoorted tc the nearest 
tenth of a second. "Sys” time is the time spent during tne 
execution of operatino system supervisory instructions and 
is reported to the nearest tenth of a second. The 
difference between "real" time and the sum of "user" and 
"sys" times indicates the amount of processor idle time. 
Idle time generally reflects the amount of time spent on 
asynchronous I/O operations. 

In addition to benchmark test i na in a single-user 
configuration# SUNTX was run for a full aay of multiuser 
program development. The system was fullv configured (Fig. 
1) and moderate to heavv system utilization was noted. 
System Users were asked to report any oroblems to the 
laboratory staff. N o system failures occurred and no 
problems were reported. This test provided an excellent 
indication of proner system ooeration as well as the 
transparency of the memory management method to system 
Users. 



C. SHARED memory allocation 

Testing of data segment allocation to shared core was 
performed on the display processor. The system was 
configured with a single terminal and tne system console. 
Swao scace and the file system were maintained on P P 0 5 disk 



units. To demonstrate the oerformance of SSUNIX, it was 
necessary to develop a method for displaying certain 
relavent system information. Three items were reauireo: the 
location of a process's data segment in memory, the state of 
the User free memory mao, and the state of each of the 
shared memory maps. This data best indicated the shared 
memory allocation/deallocation nrocess. A system call 
( M shtest" ) was developed to disolay this information at the 
display processor's console. Several test orograms which 
included shared core allocation requests ("getshr") and 
shared core deallocation requests ("f reeshr") in various 
sequences were develooed. M Shtest 11 was included in these 
proarams to disolay the required information after each 
shared core operation. This aporoach proved invaluaole in 
the debugging and refinement of SSUNIX. 

D. ANALYSIS OF RESULTS 

The results shown in Table I clearly indicate that the 
performance of UNIX, SUNIX and SSUNIX are nearly identical. 
No statistical analysis was performed on these results, but 
earlier work [6] indicates that the sampled data may have a 
standard deviation of as much as 8 percent on identical 
benchmarks run several times on the same system. System 
supervisory times t " S Y S " ) under SUNIX ana SSUNIX were found 
to be sliahtlv better than UNIX in some cases. This is a 
surorisina result in liont of the more complex memory 
management function with orocess segmentation. The 



disadvantage related to increased sweeping overhead did not 
aopear to degrade overall system performance. A probable 
explanation for this result is an offsetting oerformance 
improvement due to independent dynamic growth of aata and 
stack segments. These factors were discussed in Chapter 
III. S S U N I X ' s oerformance in a multi ported memory 
environment was validated. The tests oerformed usina 
M shtest" indicated that shared core allocation and 
deallocation of a process's data was prooerly managed. 
Additionally, since S S U N I X benchmark timing data was so 
nearly identical to that of the other systems, the data 
segment alignment capability had no sianificant effect on 
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CONCLUSIONS AND RECOMMENDATIONS 



The primary goal of this thesis# an extension of the 
UNIX memory manager to orovide data segment a 1 i a n m e n t with 
system protection# was successfully implemented in the form 
of SSUN1X. Performance results were encouraging. However# 
before the benefits of this svstem can be fully realized# 
other related development wor< in the Signal Processing and 
Disolay Laooratory is necessary. This chapter provides 
recommendations directed toward the development of a total 
system supoort oackage for the laboratory’s display 
processor. Also included is a recommendation for further 
research in the area of segmented memory management. 



A. CONTROLLED MEMORY ALLOCATION 

Several different operatina systems for the display 
processor have been developed to croviae suoport for special 
peripheral devices. Two of these systems were designed to 
provide orocess alignment in a particular area of memory! 
one for CSP 125 processes# and another for VC processes. 
The existence of a number of different operating systems# 
each with a particular application# causes a sianificant 
conf iauration control problem in the laboratory. Sine** 
SSUNIX was designed with these specific applications in 



mind 



a direct implementation of this system on tne display 



processor would simplify the 



system conf iqurat ion control 



problem. 



6. MULTIPROCESSOR INTERFACE 



As indicated in Figure 1, the PDP-11/34 slave Processor 
is presently treated as an inaependent system oerinhera) , 
The design work done by Grav f 5 1 has not yet been tested in 
the multiprocessor environment for which it was intended. 
Additionally/ the hardware interfaces for the 32 K word 
shared core area and the VG display device have not ceen 
implemented. The dashed lines in Figure l depict tne 
configuration required to comolete the mu 1 t i d rocesso r 
interface. Once this is done/ implementation of the slav^ 
processor's operating system and integration of SSUNIX into 
the multiprocessor environment could follow. Investigation 
of the communication reaui rements and protocol between the 
master processor and the slave orocessor is required. Also/ 
the i n t e r-o r oc es so r graphics support package desionea by 
Vi sco [121 must oe reviewed to ensure proper interface with 
the f 'getshr M and "freesnr" system calls of SSUNIX. Only 
slight modification to SSUNIX would oe reaui rea to establish 
this interface. One suqaestea approach is to imolement 
V i sco 1 s * r t i m e " and "nonrt i^e' 1 system calls in SSUNIX to 
perform the functions as " g e t s h r " and ”f reeshr". This 
approach has the advantaoe of reaui rinq only si mole 
modifications to SSUNIX and no modifications to the graphics 
interface routines. Another* rossioilitv is modifying rne 



Vector General routines to acaui re shared core via "getshr 



and release it via " freeshr". 



C. INVESTIGATION OF SWAPPING POLICIES 



The disadvantage of segmented memory management 
requiring a greater numoer of cony ooerations for process 
swaopinq has been stated oreviously. An interesting topic 
for further i nvest i cat i on is the development of an extension 
to S3 UNIX (or SUNIX) which imolements swaopina on a seament 
basis, Modifications to SSUNIX to supoort t h i s 
investigation would involve revision of the orocess 
scheduling routine ’’sched" ^ the orocess memory allocation 
routine ” oral 1 oc% tne routine for swapoing processes out of 
core/ "xswap", and the routine for swaooing processes into 
core/ "orswap". It is contended that / althouah the memory 
management function will be sliohtly more c o m o 1 e x / the 
actual changes required to existing routines will not 
degrade system oerformance. In fact/ since swapoing is a 
significant factor in system overhead/ an optimum swapping 
policy should enhance overall performance. 
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APPENDIX A 



CONTROL BLOCK MODIFICATIONS 



A, DOCUMENTATION FORMAT 

This apoendi x is intended to be used with a ceov of the 
source code for UNIX (Version 6), SUN IX and SSUNTX, It 
contains documentation of the modifications made to UNIX 
control blocks to implement the two new segmented systems. 
Source code for these control blocks in the UNIX form is 
found in the directory /usr/sys, Source code for the 
modified versions can be found in the directory 
/usr/sys.suni x on the disolay processor ’s file svstem, The 
format of this apoendi x and some of the documentation 
contained herein are identical to APPENDIX A of Ref. 4, 
Each control block is aescrioea under an uoper case roman 
letter. The control block name is followed by the source 
code file in which it is found. An overview and a 
description of significant data elements is provided for 
each control block. 



8, SHR M AP, share,h 
1 , Overview 

S H R ^ A D is a structure contain ina N SHARE f re° memorv 
maps of shared core regions, N S ri A R E is a tunable parameter, 
also found in M share,n'U which soecifies the number of 



shared core areas in the system 



This control bloc* is not 



founa in UNIX or SUN IX. Each map in S H P M A P is an inteaer 



array containing the physical block number ana size of an 
unallocated memory area. The maps are sorted in physical 
block number order. This conf iouration is identical to 
COREMAP and SWAPMAP. Documentation of "fnal 1 oc .c" in 
APPENDIX B describes the memory manaaement primitives which 
manipulate the free memory maos. 



2. Significant Data Elements 



a. int shmap (SHMAPS I Z3 

This is the soec i f i cat i on for a single shared 
memory mao contained in SHR^AP. SHMApSIZ is a tunable 
parameter defined in 11 share. h H • 

b. char * m <- s i z e 

This is the size of the free area in 64-bvte 

blocks. 



c . 

Degi nni ng 
this value 



char *m *-adar 

This is the ohysical block number of 
of the free area in the snared core reaion. 
is zero* it marks the end of the map. 



the 
I f 



C . SHARE* share .h 

1. Overview 

A SHAPE contains certain 
shared core region. There is 
for each of the NSHARE reoions. 



control information aoout a 
one of these control olocks 
Share is not defined in 



UNIX or SUNIX 



2 . Significant Data Elements 



a . i n t basadc r 

This is the physical block numoer of the base of 
the shared core region in memory. 



b. int niaddr 

This is the physical block number of the too of 
the shared core region. 



c . char nuse f 1 a 

This is a flaa which indicates that the shared 
core region is in use by a resident memory-sharing process. 
Further details on its use are orovidea in apoenai x B under 
the documentation of "shalloc.c" . 



d. char ckflc 

This is a flaa which indicates that no processes 
are to be allocated memory soace within the bounds of the 
shared region. Its use in *Vm a 1 1 o c ( ) " is documented in 
APPENDIX B. 



0. PROC , proc.h 

1. Overview 

One P p 0 C is allocated for each active process in the 
svstem. T he PROC exists for the life o f the process. p R0CS 
are maintained in an array called '’oroc" which is M PR0C in 
size. This array is permanently resident in main memory and 



contains all cer orocess information which cannot be swapoed 



out of main memory. 

2 . Significant Data Elements 

a . char o*- f 1 ag 

This is a word of flaas. Bit 0 of this word is 
the SLOAD flag. If it is set/ the process is resident in 
main memory. Bit 1 is the SLOCK flag. If it is set , the 
process is locked in memorv and mav not be swaopea out. In 
S SUM IX, this bit is set to lock memory-sharing processes in 
memory. Bit 2 of this word is the S S to A P flag. If it is 
set, the orocess is being swapped out. 

D . i n t p<-ada r 

This variable is present only in IJMIX. If the 
process is resident in main memory, it is the physical block 
number of the process's UVECTOR. If the orocess is swapoed 
out, it is the swap device block number of the swapped 
i mage . 

c. i n t p«-size 

This variable is present only in UNIX. It is 
the size of the process's swappable imaae in 64-pyte blocks. 

d. int p«-textp 

This is a pointer to the process's TEXT. If the 
value is zero, the process does not have snareo text. 
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e 



i n t p*-caaar 



This variable is oresent only in 3UNIX and 
SSUNIX. It is the main memory physical block number of the 
process's UVECTOR while the process is in memory. 



f . 



SSUNIX. It 
swap space. 



int p«-dadcr 

This variable is present only in S U N I x and 
is the swap device block number of the process's 
If it is zero/ the process has no swap scace. 



g . int 
This 

S-SUNIX. It is 

o^-byte bl ocxs . 

h . int 
This 

SSUNIX. It is 

blocks. 



p<-ds i ze 
v a r i a b 1 e is 
the size of 

p <- s s i z e 
variable is 
the size of 



present on 1 v 
the process's 



present only 
the process ' s 



in SUN IX and 
data segmen t i n 

in SUN IX and 
stack in 64-ovte 



E. ‘ UVECTOR/ user.h 

1. Overview 

The structure "user" is referred to as the UVECTOR. 
One of these structures is part of each swapoable process 
image. The UVECTOR contains all process data that is not 
needed when the process is not in control of the processor, 
ill h e n the Process is in control of the processor/ its UVECTQR 
resides at a fixes location in the ooeratinc system cata 
soace . 



SI 



2 . Significant Data Elements 



a . i n t u<-u i s a [ 1 1> 1 

In UNIX this arrav contains the 64-byte block 
displacements from the start of the renion of the process's 
data and stack caaes. In SUNIX and SSUNI* this array is not 
used . 



0 . 


int u«*u i sd [ 1 61 

This aray contains the orototvpes of tne 


process ' s 


user I-space and D-space page descriptor 



r eg i s t e r s . 



c . 


i nt u<*t size 

This is the size of the process's shared text 


segmen t i n 


64-byte blocks. 


d • 


l n t utas i z e 

This is the size of the process's data seament 


in 64-oyte 


blocks. 


e • 


int u f ss i z e 

This is the size of the process's stac< secment 


in 64-byte 


blocks. 



52 



I 



APPENDIX 8: MEMORY MANAGEMENT MODIFICATIONS 



A. DOCUMENTATION FORMAT 

As with APPENDIX A, this appendix is intended to be used 
with a cooy of the source code for UNIX, SUM IX and SSUNIX. 
It contains documentation of the modifications to UNIX 
memory management functions whicn were neauired to produce 
the two segmented systems. The format used here* and some 
of the aoc umen t a t i on > is identical to APPENDIX 6 of p ef. 4. 
UNIX source cooe is divided into several files containino 
related blocks of code. The functions documented in this 
aopendix are qrouoed under an uooer case roman letter and 
the name of the file in which they are found. Each function 
in each file is labeled with an arafcic numoer. The 
documentation of each function is divided into four 
subsections: parameters/ functional description/ returned 
values/ and error ccncitions. The files containing the UNIX 
functions are founa in tne directory /u s r / sy s / k en . Tne 
files containing the modified versions of the functions for 
SUN IX and SUN IX are found in the directory 
/usr/sys.sunix/ken on the display processor file system. In 
this directory/ those files which contain modifications 
specific to SSUNIX are prefixed with tne letters "sh". 
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B 



inain.c 



1 . rnainO 

a . Parameters 

This function has no Parameters. 

o. Functional Descriotion 

This is the operatinq system initiation 
function. Physical memory configuration is determined/ User 
memory space is cleared/ and all system free maos are 
initialized. Process 0 and Process 1 are created. In 

SSUNIX, the soec i f i c a t i on array for shared core 
coni iguraton, "shmem"/ is found in the file "main.c”. This 

function utilizes "shmem" to initialize the SHR^APs and 
SHAREs described in APPENDIX A. Shared core configuration 
changes are managed by modifyina the entries in "shmem". 
Upon completion of initiation tasks/ the process scnedulina 
routine/ "sched"/ is called. "Sched" then runs until the 
operating system crashes or is otherwise terminated. 

c. Returned Values 

This function does not return. 



O. Error Concitions 

An error occurs it the system clock cannot be 



estaol i shea . 
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2 . estaOur(nt/nd#ns,seo) 



a . Paramet ers 

The first three parameters are tne sizes of the 
current process's shared text ^ data and stack segments in 
64 -byte oIocks. The last parameter is a separation flag 
that is set if the process has solit instruction ana aata 
spaces. The current process’s UVECTOP is an implied 
parade ter. 

D. Functional Description 

This function first checks the validity of its 
arguments. It loads the Prototypes of the memory management 
page descriptor registers into the array u«-uisdfJ found in 
the current UVECTOR. In UNIX it also loads page start 
displacements measured in blocks from the Peginning of the 
region or text into the array u«-uisaU found in the current 
UVECTOR. The array u<-uisad is not loaded in SIJNTX and 
SSUNIX # Its values are are not required since the values of 
the parameters are placed in the variables uttsize/ u a s i z e # 
u <- s s i z e # and u^seo in the current UVECTOR. In all versions# 
" s u r e a " is called to load the actual memory management 
regi sters. 

c. Returned Values 

If the oarameters are invalid# minus one is 
returned#* otherwise# a zero is returned. 
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d. Error Cone i t i ons 

The minus one return indicates an error to the 



cal ler. 



5 . cksize(nt /nd/ns/Sep) 
a. Parameters 

The parameters are the same as *or 
"estabur(ntrnd>nSfSep) M described above. 

o. Functional Description 

This function is or^sent onlv in S U N I X and 
SSUNIX. It checks its parameters to see if they are valid. 

c. Returned Values 

If the parameters are invalid/ a minus one is 
returned. Otherwise/ a zero is returned. 

d. Error Conditions 

A minus one return indicates an error to trie 

cal ler. 

C . ma 1 1 oc . c 



1 . ma 1 1 oc ( mp / s i z e ) 
a. Parameters 

The parameters are a pointer to a free memcrv 
map array and the size in oloc<s of the region to be 



allocated from the mac 



o. Functional Oescriot ion 



This function allocates soace in main memory and 
on the swap device. If User free memory soace is to be 
allocated# the first parameter must point f o CORE MAP, and 
the size must be specified in 6 u - b y t e blocks. If swao space 
is to be allocated, the first parameter must point to 
SWAPMAP, and the size is specified in 256-word sectors. If 
shared core is to be allocated, the first oarameter must 
point to a SHR^AP, and the size is scecifieo in 64-pvte 
blocks. In SSUNIX only, this function cnecks tne global 

flag, "sharflg", if COREMAP is specified. If "sharflq" is 
set, the function must f hen check the " c k f 1 a " in each SHARE 
before allocatina soace in COREMAP. I * a "ckflg" is set, a 
free area which incluces anv part of that particular shared 
region will not be allocated. 

c. Returned Values 

If allocation is successful, this function 
returns the physical block number of the base of tne 
allocated area. Zero is returned if space is unavailaole. 

d. Error Concitions 

A zero returned value indicates allocation 
failure to the caller. 

2. mfreefmo, si ze,aa) 
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a . Parameters 



The first two parameters are the same as those 
for "fnal loc M described above. The third parameter is a 
physical block number of an area of main memory or swao 
space, 

b. Functional Oescriotion 

This function frees the soecifiea area in the 
soaci f ied free mao. If the first parameter ooints to 
COREMAP, the area is freed in the User free memory mao. If 
the first parameter points to SWAP MAP, the space is freed in 

the free mao of the swao device. In SSUMIX only, if the 

first parameter points to a SHRMAP, the area is freeo in the 
map of that particular shared core region. Sizes are in 
t>4-byte blocks if CORE MAP or a S HR MAP is specified, and in 

^56-word sectors if S W A R M A P is specified. 

c. Returned Values 

The value returned by this function is not 

chec ked. 



d. Error Concitions 

This function has no error conditions. 

3 . c kmap ( r 1 a , r ha ) 

a . Paramet er s 

The parameters are the low address and high 
address in ohvsi cal block numbers of a reaion of main memory 
soace. COREMAP is an implied parameter. 
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b. Functional Description 



This function is oresent in SSUNIX onlv. It 
checks COREMAP to determine if the soecifiea region of main 
memory is free. If the area is free, it is removed from 

COREMAP and- the map is rebuilt to reflect the removal. In 
order to rebuild the mao, several boundary alignment 
conditions are checked. The position of the free area 
boundaries in relation to the boundaries specified in the 
parameters determines the algorithm used to sort and rebuild 
the mao. This function is used in conjunction with the 
shared core allocation function, "shalloc", descriced below. 

c. Returned Values 

If the specified area is free and was removed 
from CQPEMAP, a one is returned. If anv oart of the area is 
in use, a zero is returned. 

d. Error Conditions 

This function nas no error conditions. 

4. shall oc f scname ) 
a. Parameters 

The parameter is an inteoer value which 
soecifies a particular shared core region. The p RCCs and 
TEXTs of all processes, the current process's UvECTQR, the 
SHAPEs, and the S H R M A p s are all implied parameters. 
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b. Functional Descriotion 



This function is oresent only in SSUMIX. It 
performs the shared cere allocation process Dy acaui ri na the 
region/ reservina it for memory-sharing orocesses/ and 
positioning the cal 1 er * s data segment in it. The function 
first checks the validity of its input argument. T h ^ 
w c , <flq ,, for the specified region and the global "sharflg" 
are set to orevent allocation of soace within the region 
during the acquisition process. To ensure that the calling 
process is not within the Pounds of the shared core area 
that it is tryina to acquire* it is swaooed out of memory 
using "ceswap". Since '^al loc" will not allocate space 
within the region/ when the process returns to memory it 
will not interfere with its own acaui si t i on process. The 
"nuseflg" of tne shared core area is checked to determine if 
the area has been previously acquired and reserved for 
sharing. If the area has oeen reserved* the caller’s data 
segment is allocated in the SHR^AP and tnen copied to the 
allocated space. If the area is not reserved* "ckrao" is 
called to determine if it is free. If it is not free/ the 
PPQCs are scanned to find processes with seaments in the 
area. Interfer ina orccesses are swapped out of memory until 
the region is free. " C k m a p " Performs the actual reservation 
process oy removing the region from CCREMAp. The caller’s 
data segment is then allocated in the SHRmap and cooied to 
the allocated scace. In anv case* after the process's data 
segment has been copied to the region/ the orocess imaae is 
locked in main me m ory by setting the ^LOCK flag in the PROC. 
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Returned Values 

If the shared core al location process is 

successful/ the physical block number of the base of the 
caller’s data segment is returned. If unsuccessful/ a minus 
one is returned. 

d. Error Conci t ions 

The minus one return indicates an error to tne 
caller. This value can result from one of two error 
conditions: improoer inout parameter/ or failure to allocate 

the process’s data seament to the shared core region. 

5 . shf ree(c) 

a. Parameters 

The oarameter is a oointer to the calling 
process’s PPQC. The SHARES and SHPMAPs are implied 

pa r ame t e r s . 

D. Functional Description 

This function is oresent only in SSUNIX. It is 
used to free the caller’s shared core asset. If first 
checxs to see if the caller is a memory-sharing orocess. If 
so f that process’s data segment is deallocated in the SHR^A p 
of the region that it occupies. If there are no other 
memory-sharinn processes remaining in the area/ it is freed 
in C0FE M AP and the caller’s imaae is unlockec. If any 
memory-shar ina processes remain/ the caller’s imaae is 
unlocked and swapped cut of memory. In this case/ the space 



occupied bv the data seament is not freed in C 0 R E M A P since 



the area must remain reserved 



c. Returned Values 

The values returned bv this function are not 



checked. 



d. Error Conditions 

This function has no error conditions* 



D • s i g . c 

1 . co r e ( ) 

a • Pa rame t e r s 

The current process 1 s UVECTOR, PROC , TEXT and 
address space are implied parameters* 

b . Functional Oescriotion 

This function creates a memory imaae of the 
current process's UVECTOR, data, ana stac<* In U N T X this 
function uses "estabur M to redefine the process's virtual 
address space and make the data and stack contiguous. It 
then writes the data and stack in one outout operation* In 
SUN IX and 3SUNIX this is imoossible because the data and 
stack may not be physical 1 y contiguous. Two output 

operations are reaui real one for the data and one for the 
stack. If an error occurs during an outout operation, an 
indication is left in u<-uerror in the UVECTOR of the current 
process . 
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c 



Returned Values 



This function returns zero if successful and one 
if an outout error occurs. 

d. Error Conci t ions 

The one return indicates an error to the caller. 



2 . grow ( sp ) 

a . Pa r ame t e r s 

The parameter is the value of the current 
process 1 s User stack co inter. The current process’s UVECTOR 
and PRQC are implied parameters. 



b. Functional Description 

This function is callea asynchronously when the 
current process’s stack attempts to expand byond the space 
allocated for it. This function calculates the number of 
blocks that the stack must be increased, validates the new 
stack size, and acquires the memory that is needed. In 
UNIX, "expand” is called to establish the new, 1 a r a e r 
address soace for the entire process image. In SUN IX and 
S S U M I X , this function attempts to acquire the needed space 
by in-core expansion cf the stack segment. If unsuccessful, 
it calls "ceswao" to acaui re the soace by swapping. If 
successful, it cooies the old stack to the new soace and 
frees the old memory. In all versions the newly acaui red 
soace is cleared and "estabur" is called to reload the 
memory manaoement registers. 



Returned Values 



c . 

This function returns a zero if it is 
unsuccessful and a one if it* is successful . 

d . Error Concitions 

A zero return indicates an error to the caller. 



E • s 1 p • c 

1 . schea ( ) 

a . Pa rame t e r s 

The PRQCs and TEXTs of all or ocesses are imolied 

pa rame ters. 

b. Functional Oescriot ion 

This ^unction searches for swapoed out processes 
that "deserve" to be returned to memory. It selects the 
most "deserving" orocess; acaui res space tor it Pv swaopina 
out other processes if necessary; and returns it to main 
memory. In SUNTX and SSUNIV two new functions are useo: 
"Dralloc" to acaui re main memory for the process, and 
"orswap” to swao it in. 

c. Returned Values 

This function does no** return. It is t^'e basic 
instruction loop for Process 0. It goes to sleep ana is 
reawakened about once per second by the clock function. 



d. • Error Conditions 



In UNIX# if a swao input or outout error occurs^ 
the message "swap error’' will be sent to the console and the 
system will crash. In SUNIX and SSUNIX, the swap ooerations 
occur in "prswac" so no error messaoes are Generated here. 

2 . neworoc (nrp) 



a. Parameters 

* 

The parameter is a pointer to a P p G C to oe 
estaol ished for a child process. The current process's 
UVECTOR, P R 0 C , and TEXT are implied parameters. 



b. Functional Description 

This function creates an exact duplicate of the 
current process as a child of the current process. It first 
m a < e s the appropriate entries in the child and parent PROCs 
and in the TEXT if ore exists. It then attempts to acaui re 
memory for the child process. If it is successful f it 
simply copies the parent's image to the new memory. Tf it 
fails# it swans out a copy of the parent to be returned to 
memory as the chila. In SUM IX and SSUNIX, a new function, 
"oral loc'N is used to attemot to acaui re memory for the 
chi Id. 



c. Returned Values 

This function returns zero to the parent 
process. The return to the child does not come from this 
function, but from the scnedul i no function " s w t c h " . The 
chila can identify itself as the child because "swtcn M 
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returns a one to it. This is one of the rost important and 
subtle ohenonena in UNIX. 

d • Error Concisions 





If the 


0RCC 


pointed to 


by the parameter 


i s 


a 1 ready 


a 1 1 oc a t ed 


t c 


an active 


process/ the message 


"no 


procs" 


will be sent 


t c 


the console 


and the system w 


i 1 1 


crash. 












3. 


expand("ewsi z e ) , 


exoandCnewd 


/news) 





a . Pa r ame t ers 

In UNIX# this function is called with a single 
argument* the new reaion size. In SUN IX and SSUMIX, this 
function is called with a pair of arguments: the new aata 
size and the new stack size. The current process's PPOC and 
UVECTOR are implied parameters. 

b. Functional Description 

In UNIX, this function is called whenever the 
size of the current process's memory image chances. It puts 
the new size in p s i z e in the current P^OC. If the new size 
is smaller* it simply frees the unwanted memory. If the new 
size is laraer, it attempts to ecauire the new space for tne 
process. If it succeeds* it conies the process image to the 
new area. If it fails* it causes the process to be swapped 
out with the new sizes noted in the P^GC. When it returns 
to memory* it will return at the new size. If the process 
is swapped out* this function calls "swtcn" to rescneaule 
the process immediately. In SUN IX and SSUNIX, it outs th* 
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two new sizes in o*-dsize and o+*ssize in the PPOC. In UNIX/ 
the function calls "xswao" to perform the swaopinq 
operation. In SUNIX and SSUNIX/ the new function "ceswap” 
is used. In UNIX/ " sureg M is cal I ea to loaa the memory 
management reqisters. In SUNIX and SSUNIX this is not 
necessar y . 



c. Returned Values 

The return values of this function are not 
checked. The caller has no way of knowing if the process 
was increased in size ov direct expansion or by swapping. 
In UNIX/ if the process is swapped out/ this function does 
not return to its caller. The return comes from a 
subsequent call to "swtch M after the process has returnee to 
memory . 



a. Error Conditions 

This function has no error conditions. 

4 . c eswao ( oas / oss ) 

a. Parameters 

The parameters are the current Drocess's aata 
and stack segment sizes in 64-ovte Mocks. 

b. Functional Description 

This function is present only in SUNIX and 
SSUNIX. It is called to perform core expansion swapping. 
It calls "xswap" to do the actual swaopinq and then calls 



swteh" to reschedule the process immediately 



c . Returned Values 



This function does not return to the caller. 
The return comes from a suDseouent call to " s w t c n " after the 
process has returned to memory. 

d. Error Conditions 

This function has no error conditions. 



F . s v s 1 . c 

1 . exec ( ) 

a. Parameters 

The current process’s UVECTOR, PPQC/ and TEXT 
are imolied parameters. Because this function is a svstem 
call/ the array u«-uarc[] in the UVECTOP contains additional 
arguments. See Ref. 11. 

b. Functional Description 

This system call is used by the current process 
to invoke a new program. It conies any prooram arguments to 
a Duffer/ unlinks from the old TEXT/ frees its old main 
memorv soace/ establishes a new TEXT if tne new program has 
shared text/ acaui res memorv space for the new data and 
stack segments/ clears the reaj on acquired/ reads in the new 
program’s aata/ copies the arauments to the new stack, and 
changes the memory manaae^ent registers to reflect tne new 
address soace. In UNIX/ "exoand” is called to free the old 
memorv space; in -SUNIX and SSUNIX/ a new function/ "prfree"/ 
is usea. In UNIX/ M estabur” is used to validate the new 
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memory reau i remen t s ; in 5UNIX and SSUNIX, tHe new function 
M cksize" is used. In SUNIX and SSUNIX, only the 
uninitialized portion of the data segment is cleared before 
the copy operation. 

c. Returned Values 

This system call returns to the caller only if 
it encounters an error. If no error occurs, it returns to 
the first instruction of the new orogram. 

d. Error Conditions 



This 


f unct i on 


returns an error 


t 0 


the c a 


1 1 e r 


i f 


the memory recui 


rements of 


the new program 


are 


i n v a 1 


i d . 





2 . e x i t ( ) 

a. Parameters 

The current process’s U VECTOR, P R 0 C , and TEXT 
are implied parameters. 

b. Functional Description 

This function is the system call used to 
terminate tne calling process. It clear s all signals, 
closes any open files* unlinks from the current TpXT, 
acquires a block on the swap device* copies the f irst 256 
bytes of the U VECTOR to the clock* ana frees main memory 
soace held by the process. In SUNIX and SSUNIX, tne old 
memory area is freed by the new function "prfree" • , T h e new 
function "swfree" is used to free any swap space. In SSUNIX 
only, if a process has the SLOC* bit set in its P R U C , tne 
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function "shfree" is called to free any shared core assets 
that the orocess has been allocated. 

c. Returned Values 

This system call does not return to its caller. 
The next function invoked for this orocess is "wait"/ which 
comoletes the cleanup. 

d. Error Conditions 

This system call has no error conditions. 

3 . sbreak ( ) 

a . Parameters 

The current process's UVECTGP ana PROC are 
implied parameters. Because this function is a system calif 
an aoitional arqumentf the virtual address of the new end of 
the data/ is found in the array u<-uaraU in the UVECTOR. 

b. Functional Descriction 

This function is the system call used to change 
the size of the callino orocess's data area. It calculates 
the new data size desired bv the orocess and checks fne 
validity of the process's new total memory r eou i remen t s . In 
UNIX/ "exoand" is usee to establish the new region. In UNIX 
and SSUNIX/ this function atte^ots to do the work itself. 
It puts the new size in o«-dsize in the current PROC. If the 
new size is smaller# it simolv frees the excess storace. If 
the new si z° is laraer# it ettemots to acauire it. If this 
fails# "ceswap” is called to acquire the soace oy swaooing. 
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In all systems, the newly acquired space is cleared. 

c. Returned Values 

The values returned by this function are not 

checked. 

d. Error Concitions 

If the new storage requirement is not valid, the 
new space will not be acquired and the function returns. 
This will usually cause the process to terminate abnormally 
because of a memory management error. 

G . t ex t . c 

1. x swap (p , f f , ns ) , x s w ap ( p , f f , ods , o s s ) 
a. Parameters 

In UNIX, this function is called with three 
arguments. In SUN IX and SSUNIX, it is called with four. 
The first parameter is a pointer to the proc of a process to 
be swapped out of memory. The second parameter is the 
memory free flag. In U N T X , the third parameter is the 
process image size in 64-ovte blocks. In SUNIX and SSUNIX, 
the third and fourth parameters are the sizes of the 
process's data and stack seaments in 64-ovte blocks. 

D. Functional Description 

In UNIX, this function allocates swap space for 
the process and swaps it out. In SUNIX and SSUNIX, this 
function allocates space only for those processes that do 
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not already have it. In all systems* memory is freed if the 
memory free flag is set. .This flag will not be set if this 
function was called by "neworoc" to create a cooy of the 
parent process. In SSllNTX, when this function is called to 
swap out a process witn shared core* the memory free flag is 
not set if other memory-sharinq processes remain in the 
sha red reg i on . 

c. Returned Values 

The values returned oy this function are not 

checked. 

a. Error Concitions 

If swap scace must be allocated* but none is 
available* the message "out of swao soace" will be sent to 
the console and the system will crash. If an output error 
occurs during the swao operation* the message "swap error" 
will be sent to the console and the system will crash. 

2 . xalloc(ip) 

a. Parameters 

The parameter is a oointer to the inode of rne 
text segment tnat is to be allocated or located. The 
current process's UVECTOR and PPOC and all TEXTS are imolied 
parameters. 

p. Functional Description 

This function establishes the shared text 
segment required by the current process. If the current 
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process aoes not reaui re shared text » this function simplv 
returns. If the process does reaui re shared text/ this 
function searches the array of TEXTS for a previously 
estaolished TEXT for the reauested segment. Tf one is 
found* its active-process use count is incremented. If the 
requested segment is in memory* the TEXTs in-memory count is 
incremented. If a TEXT has not been established* an 
unallocated TEXT is located and allocated to the text 
segment. Swao space is allocated for the text secment. The 
current process's address space is increased using "expand" 
to acquire space for the new text segment. The text seament 
is then read into memory and cooieo to the swap space 
allocated for it. The new memory soace acquired for the 
text segment is freed using "exoanq" in U M I X and "prfree" in 
SUNIX and SSUNIX. The address of the TEXT is placed in 
p *■ t e x t p in the current PfiOC ana the process is swapped out 
of memory. When it returns to memory* the newly established 
text segment will return with it. 

c. Returned Values 

The value returned by tnis function is not 

checked. 

d. Error Concitions 

If a TEXT must be establisneo and one is not 
availaole* the message "out of text" will oe s e n t to t n e 
console ana the svstem will crash. If swap space must oe 
allocated and none is available* the messaae "out of swao 
space" will oe sent to the console ana the system will 
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crash 



H. page.c 

1. p r a 1 1 oc ( p r ) 

a. Parameters 

The parameter is a pointer to a PPQC. The TEXT 
pointed to by the PPOC is an implied parameter. 

o. Functional Description 

This function is present only in SUNT X and 
3 S U N I X . It acquires memory soace for the process's UVECTOR, 
data seamen*-/ stack segment/ and/ if necessarv, shared text 
segment. Soace for the text segment is acaui red only if tne 
text is not resident in main memory. If allocation fails/ 
all memory space previously allocated is freed. 

c. Returned Values 

If all allocations are successful/ the physical 
block number of the base of the UVECTOR is returned. If any 
allocation fails/ a zero is returned. 

d. Error Concitions 

A return value of zero indicates an error to tne 

cal 1 e r . 



2 . p r s wap ( rp ) 



a. Parameter*; 



The first parameter is a pointer to a p ROC. The 
TEXT pointed to by the PROC is an implied parameter. 

o. Functional Description 

This function is oresent onlv in SUNIX and 
$ S U N I X . It swaos a process's U V E C T 0 R , data segment* stack 

segment, and, if necessary, text sepment into main memory. 

c. Returned Values 

The value returned by this function is not 

checked. 

d. Error Concitions 





if 


an input error occurs 


du r i 


nc 


the swao 


ooe r a t i on , 


the 


message "swao error" is 


sent 


t o 


the conso 1 e 



and the system will crash. 
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II 



APPENDIX C: SYSTEM BENCHMARKS 



A. BENCH 1, monoprogramming 



chair /usr/sys 
sh rp 1 oad 
c h d i r ken 
cc -Q -c slo.c 
c d • • 
cd dm r 

ed ipc.c < / u s r /b enc h / edc md >/dev/null 

chair /usr/bench 

cc -0 r f test .c 

bas tower<towerin>/dev/nul 1 

od /us r / sy s /c on f /mil 5 . s >/dev/null 

co /usr/unix /dev/nul I 

c ha i r /bin 

sum *>/dev/nul 1 

wait 

chdir /usr/sys/ken 
rm s I o . o 

chdir /usr/bench 
rm a . ou t 



B. BENCH 2, MULTIPROGRAMMING 

chdir /usr/sys 
s h ro 1 oad% 
chai r ken 
cc -0 -c slo.cS 

c d . . 

c d dm r 

ed ipc.c </usr/bench/eacmd >/dev/null 7 . 

chdir /usr/bench 

cc -0 rftest.ci 

bas tower<towerin>/dev/nul 1 & 

od /u s r / s y s / c on f /m . s >/dev/null& 

cd /usr/unix /dev/nul 1& 

chdir /bin 

sum *>/dev/nu 1 1 S. 

wait 

chdir /usr/sys/ken 
r m s 1 o . o 

chdir /usr/bench 
rm a . ou t 
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